1. Field of the Invention
This invention pertains in general to computer security and in particular to detecting database intrusion and data theft attempts.
2. Description of the Related Art
Databases are widespread in modern computing environments. Companies and other enterprises rely on databases to store both public and private data. Many enterprises provide publicly-accessible interfaces to their databases. For example, an electronic commerce web site typically includes a “search” field that accepts search terms and allows an end-user to search items for sale on the site. This search field is a publicly-accessible interface to a database that stores data describing the items for sale. Similarly, an application used by an enterprise, such as customer relationship management (CRM) software, utilizes a database to store its data. The enterprise application has an interface that employees can use to submit queries to the database.
At a technical level, many of these databases work by having a web server provide a web browser executing on the client with an HTML and/or JavaScript-based form. The web browser displays this form on the client, and the end-user, such as a person searching a web site or an employee accessing CRM data, provides values for the fields in the form. The end-user performs an action, such as pressing a “Submit” button, that causes the web browser to send the entered values to the server. The web server extracts the values provided by the end-user and passes them to an enterprise application. The enterprise application generates a query using the user-supplied values and sends the query to the database. The database executes the query and provides the results to the enterprise application. The enterprise application passes the results back to the web server, which in turn provides the results to the end-user.
Malicious end-users can exploit the web interface to the database to perform malicious actions such as obtaining access to confidential information. For example, in an SQL (Structured Query Language) injection attack, the attacker fills out the form using specially-crafted values. These values, when used by the enterprise application to generate a query to the database, result in a malicious query being sent to the database on behalf of the attacker. The malicious query can cause the database to reveal confidential information or perform other malicious actions.
A database intrusion detection system (DIDS) attempts to detect malicious queries. The DIDS is usually located between the enterprise application and the database so that it has visibility to the database queries and results. Typically, the DIDS is trained to recognize legitimate queries. If the DIDS recognizes an anomalous query, it logs the query and may perform other actions, such as triggering an alert to an administrator or blocking execution of the query.
Ideally, the DIDS would report the source of the anomalous query in order to allow an administrator to identify the attacker. However, the DIDS does not have access to origin information due to its position between the enterprise application and the database. In most instances, the enterprise application logs into the database using login credentials unique to the application. All queries from the enterprise application to the database thus appear to be originated by the application. While it is conceivable that the enterprise application could use different login credentials for queries from different end-users, or that the end-users could log into the database under their own credentials, such implementations are undesirable from maintenance and security standpoints. As a result, the DIDS cannot determine the true origin of an anomalous database query.
Therefore, there is a need in the art for a way to allow a DIDS to determine the origin of an anomalous query. An administrator could use such information to track down an attacker who is submitting malicious database queries.